Network Zone Identification In A Network Security System

ABSTRACT

Different network segments can have overlapping address spaces. In one embodiment, the present invention includes a distributed agent of a security system receiving a security event from a network device monitored by the agent. In one embodiment, the agent normalizes the security event into an event schema including one or more zone fields. In one embodiment, the agent also determines one or more zones associated with the received security event, the one or more zones each describing a part of a network, and populates the one or more zone fields using the determined one or more zones.

FIELD OF THE INVENTION

The present invention relates to a computer-based system for capturingsecurity events from heterogeneous and homogenous sources, andspecifically to correlating a number of security events.

BACKGROUND

Computer networks and systems have become indispensable tools for modernbusiness. Today terabits of information on virtually every subjectimaginable are stored in and accessed across such networks by usersthroughout the world. Much of this information is, to some degree,confidential and its protection is required. Not surprisingly then,intrusion detection systems (IDS) have been developed to help uncoverattempts by unauthorized persons and/or devices to gain access tocomputer networks and the information stored therein. In addition,network devices such as routers and firewalls maintain activity logsthat can be used to examine such attempts.

Intrusion detection may be regarded as the art of detectinginappropriate, incorrect or anomalous activity within or concerning acomputer network or system. The most common approaches to intrusiondetection are statistical anomaly detection and pattern-matchingdetection. IDS that operate on a host to detect malicious activity onthat host are called host-based IDS (HIDS), which may exist in the formof host wrappers/personal firewalls or agent-based software, and thosethat operate on network data flows are called network-based IDS (NIDS).Host-based intrusion detection involves loading software on the system(the host) to be monitored and using log files and/or the host'sauditing agents as sources of data. In contrast, a network-basedintrusion detection system monitors the traffic on its network segmentand uses that traffic as a data source. Packets captured by the networkinterface cards are considered to be of interest if they match asignature.

Regardless of the data source, there are two complementary approaches todetecting intrusions: knowledge-based approaches and behavior-basedapproaches. Almost all IDS tools in use today are knowledge-based.Knowledge-based intrusion detection techniques involve comparing thecaptured data to information regarding known techniques to exploitvulnerabilities. When a match is detected, an alarm is triggered.Behavior-based intrusion detection techniques, on the other hand,attempt to spot intrusions by observing deviations from normal orexpected behaviors of the system or the users (models of which areextracted from reference information collected by various means). When asuspected deviation is observed, an alarm is generated.

Advantages of the knowledge-based approaches are that they have thepotential for very low false alarm rates, and the contextual analysisproposed by the intrusion detection system is detailed, making it easierfor a security officer using such an intrusion detection system to takepreventive or corrective action. Drawbacks include the difficulty ingathering the required information on the known attacks and keeping itup to date with new vulnerabilities and environments.

Advantages of behavior-based approaches are that they can detectattempts to exploit new and unforeseen vulnerabilities. They are alsoless dependent on system specifics. However, the high false alarm rateis generally cited as a significant drawback of these techniques andbecause behaviors can change over time, the incidence of such falsealarms can increase.

Regardless of whether a host-based or a network-based implementation isadopted and whether that implementation is knowledge-based orbehavior-based, an intrusion detection system is only as useful as itsability to discriminate between normal system usage and true intrusions(accompanied by appropriate alerts). If intrusions can be detected andthe appropriate personnel notified in a prompt fashion, measures can betaken to avoid compromises to the protected system. Otherwise suchsafeguarding cannot be provided. Accordingly, what is needed is a systemthat can provide accurate and timely intrusion detection and alertgeneration so as to effectively combat attempts to compromise a computernetwork or system.

SUMMARY OF THE INVENTION

Different network segments can have overlapping address spaces. In oneembodiment, the present invention includes a distributed agent of asecurity system receiving a security event from a network devicemonitored by the agent. In one embodiment, the agent normalizes thesecurity event into an event schema including one or more zone fields.In one embodiment, the agent also determines one or more zonesassociated with the received security event, the one or more zones eachdescribing a part of a network, and populates the one or more zonefields using the determined one or more zones.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and notlimitation, in the figures of the accompanying drawings in which:

FIG. 1 is a block diagram of a network security system according to oneembodiment of the present invention;

FIG. 2 is a block diagram a distributed network security systemaccording to one embodiment of the present invention;

FIG. 3 is a block diagram of a software agent according to oneembodiment of the present invention; and

FIG. 4 is a flow diagram illustrating zone mapping according to oneembodiment of the present invention.

DETAILED DESCRIPTION

Although the present system will be discussed with reference to variousillustrated examples, these examples should not be read to limit thebroader spirit and scope of the present invention. For example, theexamples presented herein describe distributed agents, managers andconsoles, which are but one embodiment of the present invention. Thegeneral concepts and reach of the present invention are much broader andmay extend to any computer-based or network-based security system. Also,examples of the messages that may be passed to and from the componentsof the system and the data schemas that may be used by components of thesystem are given in an attempt to further describe the presentinvention, but are not meant to be all-inclusive examples and should notbe regarded as such.

Some portions of the detailed description that follows are presented interms of algorithms and symbolic representations of operations on datawithin a computer memory. These algorithmic descriptions andrepresentations are the means used by those skilled in the computerscience arts to most effectively convey the substance of their work toothers skilled in the art. An algorithm is here, and generally,conceived to be a self-consistent sequence of steps leading to a desiredresult. The steps are those requiring physical manipulations of physicalquantities. Usually, though not necessarily, these quantities take theform of electrical or magnetic signals capable of being stored,transferred, combined, compared and otherwise manipulated. It has provenconvenient at times, principally for reasons of common usage, to referto these signals as bits, values, elements, symbols, characters, terms,numbers or the like. It should be borne in mind, however, that all ofthese and similar terms are to be associated with the appropriatephysical quantities and are merely convenient labels applied to thesequantities. Unless specifically stated otherwise, it will be appreciatedthat throughout the description of the present invention, use of termssuch as “processing”, “computing”, “calculating”, “determining”,“displaying” or the like, refer to the action and processes of acomputer system, or similar electronic computing device, thatmanipulates and transforms data represented as physical (electronic)quantities within the computer system's registers and memories intoother data similarly represented as physical quantities within thecomputer system memories or registers or other such information storage,transmission or display devices.

As indicated above, one embodiment of the present invention isinstantiated in computer software, that is, computer readableinstructions, which, when executed by one or more computerprocessors/systems, instruct the processors/systems to perform thedesignated actions. Such computer software may be resident in one ormore computer readable media, such as hard drives, CD-ROMs, DVD-ROMs,read-only memory, read-write memory and so on. Such software may bedistributed on one or more of these media, or may be made available fordownload across one or more computer networks (e.g., the Internet).Regardless of the format, the computer programming, rendering andprocessing techniques discussed herein are simply examples of the typesof programming, rendering and processing techniques that may be used toimplement aspects of the present invention. These examples should in noway limit the present invention, which is best understood with referenceto the claims that follow this description.

Referring now to FIG. 1, an example of a computer-based network securitysystem 10 architected in accordance with an embodiment of the presentinvention is illustrated. System 10 includes agents 12, one or moremanagers 14 and one or more consoles 16 (which may include browser-basedversions thereof). In some embodiments, agents, managers and/or consolesmay be combined in a single platform or distributed in two, three ormore platforms (such as in the illustrated example). The use of thismulti-tier architecture supports scalability as a computer network orsystem grows.

Agents 12 are software programs that provide efficient, real-time (ornear real-time) local event data capture and filtering from a variety ofnetwork security devices and/or applications. The primary sources ofsecurity events are common network security devices, such as firewalls,intrusion detection systems and operating system logs. Agents 12 cancollect events from any source that produces event logs or messages andcan operate at the native device, at consolidation points within thenetwork, and/or through simple network management protocol (SNMP) traps.

Agents 12 are configurable through both manual and automated processesand via associated configuration files. Each agent 12 may include one ormore software modules including a normalizing component, a timecorrection component, an aggregation component, a batching component, aresolver component, a transport component, and/or additional components.These components may be activated and/or deactivated through appropriatecommands in the configuration file.

Managers 14 may be server-based components that further consolidate,filter and cross-correlate events received from the agents, employing arules engine 18 and a centralized event database 20. One role of manager14 is to capture and store all of the real-time and historic event datato construct (via database manager 22) a complete, enterprise-widepicture of security activity. The manager 14 also provides centralizedadministration, notification (through one or more notifiers 24), andreporting, as well as a knowledge base 28 and case management workflow.The manager 14 may be deployed on any computer hardware platform and oneembodiment utilizes a relational database management system such as anOracle™ database to implement the event data store component.Communications between manager 14 and agents 12 may be bi-directional(e.g., to allow manager 14 to transmit commands to the platforms hostingagents 12) and encrypted. In some installations, managers 14 may act asconcentrators for multiple agents 12 and can forward information toother managers (e.g., deployed at a corporate headquarters).

Consoles 16 are computer- (e.g., workstation-) based applications thatallow security professionals to perform day-to-day administrative andoperation tasks such as event monitoring, rules authoring, incidentinvestigation and reporting. Access control lists allow multiplesecurity professionals to use the same system and event database, witheach having their own views, correlation rules, alerts, reports andknowledge base appropriate to their responsibilities. A single manager14 can support multiple consoles 16.

In some embodiments, a browser-based version of the console 16 may beused to provide access to security events, knowledge base articles,reports, notifications and cases. That is, the manager 14 may include aweb server component accessible via a web browser hosted on a personalor handheld computer (which takes the place of console 16) to providesome or all of the functionality of a console 16. Browser access isparticularly useful for security professionals that are away from theconsoles 16 and for part-time users. Communication between consoles 16and manager 12 is bi-directional and may be encrypted.

Through the above-described architecture the present invention cansupport a centralized or decentralized environment. This is usefulbecause an organization may want to implement a single instance ofsystem 10 and use an access control list to partition users.Alternatively, the organization may choose to deploy separate systems 10for each of a number of groups and consolidate the results at a “master”level. Such a deployment can also achieve a “follow-the-sun” arrangementwhere geographically dispersed peer groups collaborate with each otherby passing primary oversight responsibility to the group currentlyworking standard business hours. Systems 10 can also be deployed in acorporate hierarchy where business divisions work separately and supporta rollup to a centralized management function.

The exemplary network security system illustrated in FIG. 1 is describedin further detail in U.S. application Ser. No. 10/308,415, entitled“Real Time Monitoring and Analysis of Events from Multiple SecurityDevices”, filed Dec. 2, 2002, which is hereby incorporated fully byreference.

The agents 12 described above are configured, in one embodiment, toperform various pre-correlation processing on the security events theyobserve at their respective monitor devices. An agent 12, for example,can normalize observed events (i.e., map events to some universal schemaused by the network security system 10), aggregate events to save memoryand bandwidth, and batch events for efficient transmission. Such agent12 functionalities, and others, are described in further detail in U.S.application Ser. No. 10/308,584, entitled “Method for Aggregating Eventsto be Reported by software agent”, filed Dec. 2, 2002, which is herebyincorporated fully by reference.

Another configuration of the network security system 10 is illustratedby a simplified diagram in FIG. 2. FIG. 2 shows a configuration in whichagents 12 are distributed at multiple remote sites that are connected tothe Internet 54. Agent 12(d) collects events from monitor device 42,which monitors the Denver LAN 30. Similarly Agent 12(e) collects eventsfrom monitor device 44, which monitors the Austin LAN 32. The manager 14collecting the security events from the agents 12 can be located at athird site, e.g., the Los Angeles headquarters, or at either site shownin FIG. 2.

In one embodiment, the Denver LAN 30 shares an address space with theAustin LAN 32. Since IP addresses are scarce and/or expensive, manycompanies reuse the same address range in two or more network segments.Using network address translation (“NAT” also referred to as “nattting”)implemented for example in routers 34 and 46, packets can be routed offthe local network segments without confusion. However, the Manager 14may have difficulty distinguishing IP addresses contained in securityevent fields.

For example, agent 12(d) may collect an attack by machine 38 targeted atfax 36, while agent 12(e) may collect an attack by machine 52 targetedat machine 50. If machine 52 has the same IP address as machine 38, thenthe source IP of both security events representing the attacks will bethe same. This may cause confusion and possible faulty correlation atthe manager 14.

Various issues related to address translation are overcome in oneembodiment of the present invention using zone labeling. In oneembodiment, a zone describes a part of the network, such as “DenverLAN.” Zones may be on a smaller scale as well, or sub-zones can befurther defined, such as “Denver: Engineering.” Any range of IPaddresses, or any collection of non-consecutive IP addresses can bedesignated as a zone.

In one embodiment, zone labeling is performed by the agents 12. In oneembodiment, zone labeling can be a part of the normalization process,but it may be performed at any time during event processing. In oneembodiment, each security event has one zone field to be populated by alabel of the zone that the monitor device and the agent 12 monitor. Forexample, agent 12(e) would label each event as “Austin Zone.”

In another embodiment, multiple zone fields can identify various zonesassociated with the security event. In one embodiment, a security eventincludes the zones of the source of the event, the destination of theevent, the monitor device that is responsible for the original event,and the agent 12 that generated the normalized event. These zones can beused to populate event fields having some descriptive name, such as“Device Zone,” “Source Zone,” “Destination Zone,” “Agent Zone,” andother similar names.

In one embodiment, the zone field contains a zone reference identifierthat can be used to address into a table containing additional zoneattributes, such as zone name, the zone's external identifier, andvarious other values or identifiers associated with the zone. In anotherembodiment, the zone field may contain any of these attributes directly.In yet another embodiment, each event can have several zone fields foreach zone identified, such as “Agent Zone ID,” “Agent Zone Name,” and soon.

Such labeling is even more useful when zones are on a smaller scale thanentire facility networks. For example, the attacker machine 38 may be inzone “Denver: Engineering,” the target router 34 may be in zone “Denver:DMZ,” the monitor device may be in zone “Denver: IT,” and the agent12(d) may be in yet another zone, or also in the “Denver: IT” zone.Various other entities and their zones may be included in otherembodiments of security events.

One embodiment of an agent 12 configured to perform zone identificationis now described with reference to FIG. 3. In one embodiment,unprocessed security events from the monitor device (e.g. IDS)associated with the agent 12 are collected by the agent 12 in an inputbuffer 60. This information is then used by the agent normalize module62, which is configured to map the data contained in the unprocessedsecurity events to a normalized event schema. In one embodiment, theevent fields included in the event schema include various zone fields.In one embodiment, these include a zone associated with an event source,a zone associated with an event destination, a zone associated with themonitor device, and a zone associated with the agent.

In one embodiment, these fields are populated by a zone mapper 66. Thezone mapper accesses a zone table 64. In one embodiment, the zone tableassociates ranges of IP addresses with zones. An example zone table isshown in Table 1 below:

TABLE 1 IP Address Range Zone Name 9.0.0.0-9.255.255.255 Public AddressSpace: IBM 56.0.0.0-56.255.255.255 Public Address Space: US PostalService 191.0.0.0-192.0.1.255   Public Address Space192.168.0.0-192.168.0.64    Denver: Engineering192.168.0.64-192.168.0.128    Denver: Marketing192.168.0.128-192.168.0.255    Denver: DMZ192.168.0.255-192.168.255.255   Private Address Space197.0.0.0-197.255.255.255 Dark Address Space

Table 1 above is only a simplified example. A real world zone table 64may specify one hundred or more zones, and cover the entire range ofpossible IP addresses. The zone mapper 66 thus uses the zone table 64 tomap certain IP addresses to zones according to the associations providedby the zone table 64. For example, in the source IP of an event is192.168.0.55, then the zone mapper 66 would populate the “Source Zone”filed with “Denver: Engineering.”

In one embodiment, the zone table 64 shown in Table 1 would be residenton agent 12(d) on the Denver LAN 30. In one embodiment, the zone table64 of agent 12(e) describes the zones of the Austin LAN 32 instead ofthe Denver LAN 30 in the same IP address range.

One embodiment of zone identification is now described with reference toFIG. 4. In block 102, the agent receives the raw unprocessed securityevent from the monitor device, such as a firewall, router, or IDS. Inblock 104, the agent determines the zone to which the source of thesecurity event belongs.

In block 106, the agent determines the zone to which the destination ofthe security event belongs. If the destination is not on the localnetwork monitored by the device associated with the agent, then the zoneof the destination may not be accurately determined, since thedestination IP address may be translated before delivery at a remotesite.

In block 108, the agent determines the zone to which the monitor devicethat generated the security event belongs. Since the monitor device willgenerally not shift zones on a regular basis, the device zone may befixed at agent configuration. In one embodiment, the device IP addressis mapped to a zone for each security event.

In block 110, the agent determines the zone to which the agent itselfbelongs. Since the agent will generally not shift zones on a regularbasis, the agent zone may be fixed at agent configuration. In oneembodiment, the agent's IP address is mapped to a zone for each securityevent.

In block 112, the agent generates a normalized security event. In oneembodiment, this includes populating the various zone fields with theappropriate zones determined in blocks 104, 106, 108, and 110. Thenormalized event may undergo additional processing before being sent onto a manager.

In other embodiments, zones other than the four zones discussed abovecan also be determined and used to further identify the security event,such as a target and attacker zones, where there are different fromsource and destination. In yet other embodiments, less than four zonesmay be used. In one embodiment, only one of the four zones discussedabove is used, e.g., the monitor device zone. Other embodiments can useany two or any three of the zones discussed above.

The manager 14 can use the zone fields of the normalized security eventsin any number of ways. In one embodiment, it can use it to keep track ofevents from various network segments with overlapping address spaces.Correlation rules can also be created that respond to the observation ofcertain zones, such as prohibited zones. Furthermore, by distributingthe zone identification to the agents, the manager 14 is spared thiscomputational task.

Thus, a network security system has been described. In the forgoingdescription, various specific values and data structures were givennames, such as “security event” and “zone table,” and various specificmodules, such as “agents” and “agent normalize module” have beendescribed. However, these names are merely to describe and illustratevarious aspects of the present invention, and in no way limit the scopeof the present invention. Furthermore, various modules, such as themanager 14, and the agents 12 in FIG. 1, can be implemented as softwareor hardware modules, or without dividing their functionalities intomodules at all. The present invention is not limited to any modulararchitecture either in software or in hardware, whether described aboveor not.

What is claimed is:
 1. A method performed by a distributed softwareagent of a network security system, the method comprising: receiving asecurity event from a network device monitored by the agent; normalizingthe security event into an event schema including one or more zonefields; determining one or more zones associated with the receivedsecurity event, the one or more zones each describing a part of anetwork; and populating the one or more zone fields using the determinedone or more zones.
 2. The method of claim 1, wherein determining one ormore zones comprises determining a zone associated with a source of thereceived security event.
 3. The method of claim 2, wherein determiningthe zone associated with the source of the received security eventcomprises mapping a source Internet protocol (“IP”) address to the zoneassociated with the source of the received security event, the zonecomprising a range of IP addresses.
 4. The method of claim 3, furthercomprising mapping the determined zone associated with the source of thereceived security event to a zone name, and populating a zone name fieldof the normalized security event.
 5. The method of claim 1, whereindetermining one or more zones comprises determining a zone associatedwith the network device monitored by the agent.
 6. The method of claim5, wherein determining the zone associated with the network devicemonitored by the agent comprises mapping a network device Internetprotocol (“IP”) address to the zone associated with the network deviceresponsible for generating the received security event, the zonecomprising a range of IP addresses.
 7. The method of claim 1, whereindetermining one or more zones comprises determining a zone associatedwith the agent.
 8. The method of claim 7, wherein determining the zoneassociated with agent comprises mapping an Internet protocol (“IP”)address of the agent to the zone associated with the agent, the zonecomprising a range of IP addresses.
 9. The method of claim 1, whereindetermining one or more zones comprises determining a zone associatedwith a destination of the received security event.
 10. The method ofclaim 9, wherein determining the zone associated with the destination ofthe received security event comprises mapping a destination Internetprotocol (“IP”) address to the zone associated with the destination ofthe received security event, the zone comprising a range of IPaddresses.
 11. The method of claim 1, wherein determining one or morezones associated with the received security event comprises mapping anInternet protocol (“IP”) address to a zone, wherein the zone comprises arange of IP addresses.
 12. The method of claim 11, wherein mapping theIP address to a zone comprises mapping the IP address to a zone and asub-zone, wherein the sub-zone comprises a range of IP addresses withinthe range of the zone.
 13. A distributed agent of a network securitysystem, the agent comprising: an input buffer to receive a securityevent from a network device monitored by the agent; a zone tableconfigured to provide a mapping between internet protocol (“IP”)addresses and zones; a zone mapper to determine one or more zonesassociated with the received security event using the zone table; and anagent normalize module to generate a normalized security event based onthe received security event, the normalized security event including thedetermined one or more zones.
 14. The agent of claim 13, wherein the oneor more zones include a zone associated with a source of the receivedsecurity event.
 15. The agent claim 13, wherein the one or more zonesinclude a zone associated with a destination of the received securityevent.
 16. The agent of claim 13, wherein the one or more zones includea zone associated with the network device that generated the receivedsecurity event.
 17. The agent of claim 13, wherein the one or more zonesinclude a zone associated with the agent.
 18. A method preformed by amanager of a network security system monitoring a network, the methodcomprising: receiving a first security event from a first distributedagent of the network security system, the first distributed agentconfigured to receive security events from a first network devicemonitoring a first portion of the network, the security event includingan identifier of the first portion of the network; and receiving asecond security event from a second distributed agent of the networksecurity system, the second distributed agent configured to receivesecurity events from a second network device monitoring a second portionof the network, the second security event including an identifier of thesecond portion of the network.
 19. The method of claim 18, wherein thefirst portion of the network at least partially shares an address spacewith the second portion of the network.
 20. The method of claim 19,wherein the address space comprises a range of Internet protocol (“IP”)addresses.
 21. The method of claim 18, further comprising correlatingthe first and the second security events using a rules engine.
 22. Themethod of claim 18, wherein the identifier of the first portion of thenetwork comprises an identifier of a portion of the network where asource of the first security event resides.
 23. The method of claim 18,wherein the identifier of the first portion of the network comprises anidentifier of a portion of the network where the first distributed agentresides.
 24. The method of claim 18, wherein the identifier of the firstportion of the network comprises an identifier of a portion of thenetwork where the first network device resides.
 25. A manager of anetwork security system, the manager comprising: an agent manager toreceive a first security event from a first distributed agent of thenetwork security system, the first distributed agent configured toreceive security events from a first network device monitoring a firstportion of the network, the security event including an identifier ofthe first portion of the network, wherein the agent manager is also toreceive a second security event from a second distributed agent of thenetwork security system, the second distributed agent configured toreceive security events from a second network device monitoring a secondportion of the network, the second security event including anidentifier of the second portion of the network; and a rules engine tocorrelate the first and second security events using the identifier ofthe first portion of the network and the identifier of the secondportion of the network.
 26. The manager of claim 25, wherein the firstportion of the network at least partially shares an address space withthe second portion of the network.
 27. The manager of claim 26, whereinthe address space comprises a range of Internet protocol (“IP”)addresses.
 28. A normalized event schema for a security eventcomprising: an agent zone field to identify a zone to which adistributed agent of a network security system belongs.
 29. The eventschema of claim 28 further comprising: a device zone field to identify azone to which a monitor device that generated the security eventbelongs; a source zone field to identify a zone to which a source of thesecurity event belongs; and a destination zone field to identify a zoneto which a destination of the security event belongs.
 30. Amachine-readable medium having stored thereon data representinginstructions that, when executed by a processor, cause the processor toperform operations comprising: receiving a security event from a networkdevice monitored by the agent; normalizing the security event into anevent schema including one or more zone fields; determining one or morezones associated with the received security event, the one or more zoneseach describing a part of a network; and populating the one or more zonefields using the determined one or more zones.